home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940366.txt < prev    next >
Internet Message Format  |  1994-11-13  |  22KB
  1. Date: Fri,  4 Nov 94 04:30:31 PST
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: List
  6. Subject: Ham-Digital Digest V94 #366
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Fri,  4 Nov 94       Volume 94 : Issue  366
  11.  
  12. Today's Topics:
  13.                *** Q: WHAT KIND OF PEOPLE ON THE NET ?
  14.                    9600bd radio's ?? NOT ! (2 msgs)
  15.                              Bad messages
  16.                Computer <--> Modem <--> Modem <--> TNC
  17.                       IM_Mac1.0b28d.sea.hqx.text
  18.                           MFJ1270C vs. 1270B
  19.                  NoCal OO goes after Packet BULLetins
  20.           Pactor, HF, Binary File Transfers ( CDN Question)
  21.                             RTTY Question
  22.                              unsubscribe
  23.  
  24. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  25. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  26. Problems you can't solve otherwise to brian@ucsd.edu.
  27.  
  28. Archives of past issues of the Ham-Digital Digest are available 
  29. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  30.  
  31. We trust that readers are intelligent enough to realize that all text
  32. herein consists of personal comments and does not represent the official
  33. policies or positions of any party.  Your mileage may vary.  So there.
  34. ----------------------------------------------------------------------
  35.  
  36. Date: 3 Nov 1994 17:05:08 GMT
  37. From: cisitm@albert.cad.cea.fr (Pierre Didierjean)
  38. Subject: *** Q: WHAT KIND OF PEOPLE ON THE NET ?
  39.  
  40. I'd like to know what kind of people i find on the net.
  41.  
  42. Students, Commercials, Adminitrations, Scientifics or what ??
  43.  
  44. Is anybody knows that or have statistical results ?
  45.  
  46.  
  47. What are YOU doing in life ?
  48.  
  49. I am a system administrator.
  50.  
  51.  
  52. Thanks for the answers and sorry for my english .....
  53.  
  54.  
  55.  
  56. Bye
  57.  
  58.  
  59. +-----------------------------------------------------------------------------+
  60. |        Pierre DIDIERJEAN                           |
  61. |                                          |
  62. |        Administrateur Systeme UNIX                      |
  63. |        Cisi, Aix-en-Provence                           |
  64. |        France                                  |
  65. +-----------------------------------------------------------------------------+
  66. |    email :     cisitm@albert.cad.cea.fr                   |
  67. +-----------------------------------------------------------------------------+
  68.  
  69. ------------------------------
  70.  
  71. Date: 3 Nov 1994 16:31:12 GMT
  72. From: hadleyv@et.byu.edu (Vince B. Hadley)
  73. Subject: 9600bd radio's ?? NOT !
  74.  
  75.  (joopv@etprs.phys.tue.nl) wrote:
  76. : Since some time now several manufacterers of ham radio equipment offer
  77. : '9600 bd ready' vhf/uhf transceivers. I got one of these for some tests,
  78. : and was very surprised with the results. This is a brandnew mobile uhf rig,
  79. : FM only, from one of the 'big three' brands. The price is in the $500-$600
  80. : range.
  81. : 
  82. : Turnaround time : TX to RX is 120 ms.  RX to TX is 140 ms
  83. : 
  84. <------------------ snip snip -------------------------------------->
  85. : measurements : receiving was ok, about 98 % of all packets were decoded ok.
  86. : But the transmitter produced only 55 % readable packets !!
  87. : 
  88. : This is clearly a PLL-transceiver which is modulated at the VCO from the PLL.
  89. : 
  90. : How can it be that this rig is being sold as '9600bd ready' ? Do they have
  91. : different 9600bd modems in Japan? The G3RUH / K9NG modem system needs a flat
  92. : frequency response from 20 Hz to 6 kHz.
  93. : 
  94. : And what about those turnaround times ? 120 ms is IMHO totally unusable
  95. : for 9600bd packet. This thing sure is going to produce lots of collisions 
  96. : on busy channels !
  97. : 
  98. : Joop, PE1DNA.
  99. : 
  100.  
  101. I would love to see someone do as thorough a set of tests on the TH-78A to
  102. see how it performs on 440 at 9600Kbd and on 2m at the highest rate possible.
  103. I would like to know how this radio would perform.  I am willing to bet, with
  104. so many of them out there, that many others would also like similar data to
  105. consider.  (In other words, can the radio be used for such purposes at all,
  106. at least for those who just don't have the cash right now to buy another 
  107. dedicated radio for packet.  And to put it another way as well, "Is it even
  108. worth getting a 9600Kbd modem to use on it?", am I trying to do just too much?
  109. Thanks for any responses that can be given.
  110.  
  111. 73,
  112.  
  113. --
  114. Vince Hadley              | 
  115. KA7GVQ                    | 
  116. hadleyv@bones.et.byu.edu  | 
  117.  
  118. ------------------------------
  119.  
  120. Date: 2 Nov 94 20:28:00 GMT
  121. From: joopv@etprs.phys.tue.nl ()
  122. Subject: 9600bd radio's ?? NOT !
  123.  
  124. steve.diggs@totrbbs.atl.ga.us (Steve Diggs)  writes:
  125.  
  126. >-> From: joopv@etprs.phys.tue.nl ()
  127. >-> Subject: 9600bd radio's ?? NOT !
  128.  
  129. >-> I am wondering if anybody did the same tests on so-called '9600bd
  130. >-> ready' transceivers. Especially the FM rigs, the allmode rigs should
  131. >-> be ok because they have a separate FM modulator, and don't use the
  132. >-> PLL for modulation.
  133.  
  134. >Hi Joop,
  135. >The East Atlanta LAN, a packet experimenters group here in Atlanta, has
  136. >begun operations with our first general purpose 9600 digi. While we
  137. >haven't done a good statistically based RF performance test of various
  138. >transcievers yet, our experience with the "9600 ready" rigs has been
  139. >good - when used with a TNC that has a sound G3RUH implementation to
  140. >start out with. The two factors are inexorably tied; bad modem/radio
  141. >matchup; poor performance. The Paccom Sprint2 is an excellent performer
  142. >in terms of low distortion in the transmitted eye to the xcvr; so is the
  143. >PK232/TAPR 9600, KPC9612, and KPC Data engine. The MFJ1270 + their G3RUH
  144. >implementation is just terrible. I maintain that one of the sound TNC
  145. >performers noted here with a "big three" 9600 ready xcvr. will produce
  146. >better-than-acceptable performance on-air.
  147.  
  148. I used original G3RUH modems for my tests. Packet controllers were 8530
  149. ISA-PCboards.
  150.  
  151. >-> And what about those turnaround times ? 120 ms is IMHO totally
  152. >-> unusable for 9600bd packet. This thing sure is going to produce lots
  153. >-> of collisions on busy channels !
  154.  
  155. >Boy, are we really operating in the blind! We operate with TXD set to 22
  156. >and it performs beautifully! Based on what you say here, I'm going to
  157. >cut it down to 13-15 and see how it does!
  158.  
  159. What SLOTTIME is being used by the 9600bd users ? When the SLOTTIME of 
  160. someone who is going to transmit a packet is smaller than the PTT-to-RF_OUT 
  161. time of someone who just started to key the PTT, a collision is the result.
  162. (when the p-persist falls through)
  163.  
  164. So as far as i can see it, the PTT-to-RF_OUT time should be at least several
  165. times smaller than de SLOTTIME being used on a certain channel.
  166.  
  167. The shortest packet is about 160 bits, or (including bit stuffing etc) about
  168. 25 ms data length. Adding 120 ms txdelay gives a very bad efficiency..
  169. Of course there are a lot of the longer packets, but real-life packet
  170. situations don't have a very high average transmission length.
  171.  
  172. >results. About 3 months ago, James Miller suggested a new approach to
  173. >me: try a "two point modulation" approach, wherein both the VCO AND the
  174. >master reference oscillator are modulated with the 9600 audio. In this
  175. >manner, the cancellation effect of the PLL is eliminated. I have even
  176. >found a company, MX*COM, which makes a chipset to facilitate this
  177. >approach. I haven't had time to try it, but it's on this winter's list
  178. >of projects. If such an approach were to work, it would open 9600 packet
  179. >to MANY, MANY hams who own run-of-the-mill FM only rigs. Any ideas here?
  180.  
  181. Two point modulation is a well known technique (exept appearently in Japan
  182. :-( ) but the technical impact is of course much bigger than just finding
  183. 2 points for direct fm on a rf board. 
  184.  
  185. I have only one (1) modification for a PLL rig which is done with 2-point
  186. modulation. All the others just inject the lf into the VCO.
  187.  
  188. >I look forward to your feedback, hoping that we can open this field up a
  189. >lot of creative work!
  190.  
  191. >Regards,
  192. >Steve Diggs, President
  193. >East Atlanta LAN
  194.  
  195. ------------------------------
  196.  
  197. Date: Wed, 2 Nov 1994 00:57:43 GMT
  198. From: sww@csuohio.edu (Steve Wolf)
  199. Subject: Bad messages
  200.  
  201. : I am W5/F6CNB (not F6FNB) and i run a forwarding only BBS in Texas.
  202. : This BBS has forwarding with 15 BBS in North America and also with 15 BBS 
  203. : outside the USA/CANADA. THIS BBS IS NEVER THE FIRST FORWARDER because
  204. : it has no users. (I run a separate BBS for the Houston area users.)
  205. : According to the present FCC rules, it cannot be responsible for bad messages.
  206. : The message has been written by somebody with an usurpated callsign.
  207. : Rejecting this callsign is not a solution.
  208. : 
  209. : For your information, the BBS handles more than 1000 messages per day.
  210. : The total daily traffic is around 10 Megabytes. Most of the messages are
  211. : forwarded within 15mn.
  212. : 
  213. : 73s Remi W5/F6CNB Sugar Land Texas
  214. : 
  215. : PS: I am not portable but i own a reciprocal FCC license
  216.  
  217. Yeah, yeah, yeah ... you and grumpy old W0RLI seem intent on reminding
  218. the net of your 100 zillion message a year service.  Many of the readers
  219. here are doing the exact same thing.  Don't pat a hole in your back.
  220.  
  221. Yes, you are the first forwarder in the United States.
  222.  
  223. Yes, you should trap message with bad language.
  224.  
  225. YES, YOU DO HAVE A RESPONSIBILITY TO AMATEUR RADIO.
  226.  
  227. Irregardless of what the FCC Part 97 says, it is trivial to stop this
  228. from happening.  Like Hank said, if your software doesn't do what you
  229. need it to do, change software.  What software are you running?  Can you
  230. trap bad language?
  231.  
  232. What you are saying above is that you have no intention of doing anything.
  233. We can expect further problems.  How many times do you think it will take
  234. before the FCC does codify "the first forwarder in the United States or
  235. its possessions"?
  236.  
  237. 73,
  238. Steve
  239.      Internet        :  no8m@hamnet.wariat.org
  240.      Amateur Radio   :  no8m@no8m.#neoh.oh.usa.na (at 100k in '94, too!)
  241.      MSYS Mail List  :  msys-request@hamnet.wariat.org ("info" in subject)
  242.  
  243. ------------------------------
  244.  
  245. Date: 4 Nov 1994 04:16:10 GMT
  246. From: bd27015@bingsuns.cc.binghamton.edu (David J. Graff)
  247. Subject: Computer <--> Modem <--> Modem <--> TNC
  248.  
  249. Jeff Okleberry (jeffo@syseng.slc.unisysgsg.com) wrote:
  250.  
  251. : `?
  252.  
  253. : I have a couple questions about using modems to commuicate between
  254. : computers that I hope somebody on the net can help me with.
  255.  
  256. : Here is my problem. I have a ham radio TNC which runs on a RS-232 port
  257. : (Figure 1).
  258.  
  259. :  ____________                                                 _______
  260. : |            |                     RS-232                    |       |
  261. : |  Computer  |-----------------------------------------------|  TNC  |
  262. : |____________|                                               |_______|
  263.  
  264. :                                  Figure 1   
  265.  
  266.  
  267. ok Jeff...this TNC is used with a com port (usually com1-com4) now you
  268. should have at the least 2 com ports (both female) usually one is a
  269. 9-pin (usually com1) and one 25 pin (usually com2)
  270.  
  271. : I have a new computer which does not have any free modem ports, but does
  272. : have an internal modem.  I have an extra stand alone modem and I was
  273. : wondering if it is possible to use the modems so I can commuicate with
  274. : my TNC (Figure 2).
  275.  
  276. as for what you are suggesting you'd need a computer on the other end
  277. to run the second modem then the TNC.....the TNC cannot control the
  278. modem...
  279.  
  280. :  ____________            _____               _____            _______
  281. : |            |  RS-232  |     |  Telephone  |     |  RS-232  |       |
  282. : |  Computer  |----------|Modem|-------------|Modem|----------|  TNC  |
  283. : |____________|          |_____|             |_____|          |_______|
  284.  
  285. :                                   Figure 2            
  286.  
  287.  
  288. : My second question is it possible to do the same thing in Figure 2 with
  289. : two computers?  A follow-on question is can I use my house's
  290. : internal telephone  wiring or do
  291. : I need to run a direct link between the two modems?
  292.  
  293. you just can't do it....the modems themselves need to have line
  294. voltage to "see" a carrier 
  295.  
  296. --Dave Graff
  297.  
  298. --
  299. This is the .sig:
  300. Dave Graff      a.k.a      The Phlatline
  301.  
  302. address: bd27015@bingsuns.cc.binghamton.edu
  303. Call Sign: KB2RUM
  304. Packet address: under construction
  305. =-=-=-=
  306. Without C we'd have to program in PASAL, BASI, and OBOL
  307. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  308. Geek - Once used to describe people who bit heads off of chickens and
  309. performed other tasteless acts for money, now a term of endearment to
  310. describe smart, socially maladjusted future millionaires.  (Can you
  311. say Bill Gates?)
  312.  
  313.                 --Link magazine, October '94
  314.  
  315. ------------------------------
  316.  
  317. Date: 4 Nov 94 10:38:04 GMT
  318. From: adam@iag.TNO.NL (Adam van Gaalen PA2AGA)
  319. Subject: IM_Mac1.0b28d.sea.hqx.text
  320.  
  321.  
  322. Release Notes - IM/Mac 1.0b28d
  323.  
  324. - Did not test for the availability of Desktop Manager ToolBox calls
  325.   before using them.
  326.  
  327. - Scanning of the 'alias' file was in error. Two or more tabs/spaces
  328.   before the '#' or ';' comment character filled your hard disk with
  329.   rubbish outbound mail.
  330.  
  331. - The 'Remove' button in the 'Send to' dialog is changed to '<<
  332.   Remove <<'.
  333.  
  334. - Remembers printer settings across sessions.
  335.  
  336. - When you had an 'alias' file with only one or two entries and
  337.   replied to a message for which you used the return path such could
  338.   generate rubbish outbound mail.
  339.  
  340. - Remembers across sessions the last used folder in 'Save As...',
  341.   'Append...', 'Decode...' and 'Send File...'. Will not attempt to mount
  342.   ejected volumes.
  343.  
  344. - Did not restore screen copy after removing the 'Decode...' dialog.
  345.   This left a locked handle that fragmented the heap.
  346.  
  347. - Segment 4 was not unloaded when canceling out of the 'Send...'
  348.   dialog.
  349.  
  350. - Segment 17 was not unloaded when the help window was called with
  351.   shift-command-?.
  352.  
  353. Tuesday, November 1, 1994 - 17:51:22 UTC
  354.  
  355. Best 73's, es cuagn de Ivo, ON1XK @ ON6AR.#AN.BEL.EU [44.144.8.5]
  356. On Wednesday, November 2, 1994 at 06:25:57 +0000 UTC
  357.  
  358.  
  359. PS (by PA2AGA)
  360.  
  361. This version obsoletes all versions of info-mac/comm/radio-im-mac in
  362. the Sumex-Aim archives.
  363.  
  364. The new IM/Mac has (hopefully) been uploaded to oak.oakland.edu, to
  365. the directory /pub/hamradio/mac/digital and to ftp.ucsd.edu, to directory
  366. /hamradio/packet/tcpip/incoming. If it's not there (anymore), then look
  367. at /hamradio/packet/tcpip/mac.
  368.  
  369. ------------------------------
  370.  
  371. Date: 4 Nov 94 02:41:35 GMT
  372. From: pandora!daniel (W. Daniel)
  373. Subject: MFJ1270C vs. 1270B
  374.  
  375. Can anyone tell me the difference between the MFJ 1270C and 1270B TNCs? I am
  376. especially interested if I can simply upgrade with a ROM change. I would be
  377. further interested if anyone can help me get a copy of the 1270C ROM code. I am
  378. also interested to know if 1.1.6 is the latest firmware version for TAPR?
  379. Thanks.
  380.  
  381. 73 de 9V1ZV,
  382. Daniel
  383. -- 
  384. +-------------+-------------------------------------+
  385. | Daniel Wee  | daniel%pandora@csah.com             |
  386. | 9V1ZV       | 9V1ZV @ 9V1VS.SGP.AS --             |
  387. | UUCP1.12b   | daniel.wee@f516.n600.z6.fidonet.org |
  388. +-------------+-------------------------------------+
  389. ** It is great wisdom not to rush into action nor
  390.    obstinately hold our own opinions ** Thomas A Kempis
  391.  
  392. ------------------------------
  393.  
  394. Date: 3 Nov 1994 18:14:40 GMT
  395. From: hanko@wv.mentorg.com (Hank Oredson)
  396. Subject: NoCal OO goes after Packet BULLetins
  397.  
  398. In article <1994Nov2.032455.26815@news.csuohio.edu>, sww@csuohio.edu (Steve Wolf) writes:
  399. |> Hank Oredson (hanko@wv.mentorg.com) wrote:
  400. |> : Nope, because AX.25, by it's very nature, is not used for one-
  401. |> : way communications.  Oh yes, you might say, it COULD be
  402. |> : (there are UI frames!), but it's not.
  403. |> :
  404. |> 
  405. |> But is is broadcasting none the less.
  406. |> 
  407. |> I think it was Todd Little that that quoted the definition of broadcasting.
  408. |> 
  409. |> From Part 97.3(a) ... (10) ... Broadcasting - Transmissions intended for
  410. |> reception by the general public, either direct or relayed.
  411.  
  412. Steve, try real hard here ... read the above ... about "transmissions"
  413. and "general public" and "intended".  Give it a shot, you can probably
  414. figure out what those words mean.
  415.  
  416. |> 
  417. |> Clearly, a BBS phone port with a annonymous check-in allows the public access
  418. |> to relayed transmissions.  There are LOTS of phone ports that allow
  419. |> anonymous check-ins.
  420.  
  421. Wrong.  It allows the public (if the sysop so chooses) access to some
  422. files on a computer.  Has nothing (zilch, zip, nada) to do with 
  423. "transmissions" or "broadcasting" or for that matter "radio", not to
  424. mention "amateur radio".
  425.  
  426. Try really hard Steve, this is NOT rocket science.
  427. The words really do mean just what they say.  Amazing!
  428.  
  429. |> So, originators of bulletins which are sent by any means to a BBS that has
  430. |> a public phone port that are not about amateur radio would fall under
  431. |> broadcasting.
  432.  
  433. Would you like to run this by me again?
  434.  
  435. |> Broadcasting does not require a one-way transmission.  It would appear that
  436. |> an ax.25 connection between two stations can still be use for broadcasting.
  437.  
  438. Um, how could that happen?
  439.  
  440. Steve, you are REAL confused here.  Go back to the definitions section
  441. of part 97, and read that first.  Make some notes on what the various
  442. technical terms ("transmissions", "broadcasting", "transmitted")
  443. mean, then read the above again.
  444.  
  445. |> (Bet we are going to move on and say that a bulletin about quilting was
  446. |> targeted solely at the amateur population.  Let me guess ... ANY bulletin
  447. |> entered on packet is to be assumed to be aimed solely at the amateur radio
  448. |> population.)
  449.  
  450. Ah!  You have GOT it at last!
  451.  
  452. Who ELSE would an amateur station transmit this information to?
  453. In fact, it would not be legal for an amateur station to transmit
  454. this information to anyone BUT another ham.
  455.  
  456. By "targeted" you probably mean exactly the same thing that the FCC
  457. means with the term "intended" in part 97.3
  458.  
  459. Simple, isn't it?
  460.  
  461. I'm still curious what you are attempting to accomplish with the
  462. arguments you are making.  What's your agenda?
  463.  
  464.    ...  Hank
  465.  
  466.  
  467. -- 
  468.  
  469. Hank Oredson @ Mentor Graphics             Library Operations
  470. Internet     : hank_oredson@mentorg.com    "Parts 'R Us!"
  471. Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
  472.  
  473. ------------------------------
  474.  
  475. Date: 3 Nov 1994 02:18:27 GMT
  476. From: Cecil_A_Moore@ccm.ch.intel.com
  477. Subject: Pactor, HF, Binary File Transfers ( CDN Question)
  478.  
  479. In article <seeler.148.783690867@upei.ca>, David Seeler <seeler@UPEI.CA> wrote:
  480. >
  481. >I was wondering if anyone has come across a terminal program which permits 
  482. >the transfer of binary data or 8 bit data via pactor.
  483.  
  484. Does UUENCODE and UUDECODE work for amateur packet like it does for internet?
  485. Thanks in advance.
  486. -- 
  487. 73, Cecil, KG7BK, OOTC   (All my own personal fuzzy logic, not Intel's)
  488.  
  489. ------------------------------
  490.  
  491. Date: 3 Nov 1994 18:22:49 GMT
  492. From: hcheyney@magnus.acs.ohio-state.edu (Harold E Cheyney)
  493. Subject: RTTY Question
  494.  
  495. Just recently started working RTTY using a Kantronics KAM
  496. TNC, a Kenwood TS-530s, and a dumb terminal.  I find that
  497. I can copy rather weak signals as long as they are in the
  498. clear but QRM on nearby frequencies seems to desensitize
  499. the TNC.  Will a narrow CW filter work with RTTY?  How
  500. narrow?
  501.  
  502. Please E-mail.    
  503.  
  504. Thanks
  505.  
  506. ------------------------------
  507.  
  508. Date: 4 Nov 94 02:50:51 GMT
  509. From: Doughengst@aol.COM
  510. Subject: unsubscribe
  511.  
  512. unsubscribe doughengst@aol.com ham-digital
  513.  
  514. ------------------------------
  515.  
  516. Date: Thu, 3 Nov 1994 18:18:18 GMT
  517. From: geertj@ripe.net (Geert Jan de Groot)
  518.  
  519. References<38lqunINNsmo@s850.mwc.edu> <390i5p$15l6@info2.rus.uni-stuttgart.de>, <1994Oct30.230618.19254@ke4zv.atl.ga.us>
  520. Subject: Re: Multi mode VHF/UHF recommendation?
  521.  
  522. In <1994Oct30.230618.19254@ke4zv.atl.ga.us> gary@ke4zv.atl.ga.us (Gary Coffman) writes:
  523.  
  524. >In article <390i5p$15l6@info2.rus.uni-stuttgart.de> moritz@ipers1.e-technik.uni-stuttgart.de () writes:
  525. >>>I'm interested in recommendations for a multi mode transceiver which
  526. >>>will work at least 2m/70cm and maybe 1.2ghz.  Are there any comparisons
  527. >>>around for the units sold by Icom, Kenwood and Yaesu?
  528.  
  529. >Alas, aside from the SSB Electronics units imported from Germany,
  530. >which cost more than a good HF rig here, there aren't any suitable
  531. >transverters on the US market. 
  532.  
  533. The RSGB has a book available ('VHF/UHF DX-ing' which describes
  534. serious transverters. One of the authors G3SEK is on the net
  535. so he will probably correct it if I have the title wrong.
  536.  
  537. The chapters about power amplifiers are fun to read, even if
  538. you don't want to build one.
  539.  
  540. Geert Jan
  541.  
  542. ------------------------------
  543.  
  544. Date: 3 Nov 1994 02:27:41 GMT
  545. From: pcr@ic.net (phil reed)
  546.  
  547. References<395ur8$uic@snoopy.jh.org> <398, <Cynp9B.MAE@wang.com>
  548. Subject: Re: NoCal OO goes after Packet BULLetins
  549.  
  550. In article <Cynp9B.MAE@wang.com>, dbushong@wang.com (Dave Bushong) says:
  551. >
  552. >little@iamu.chi.dec.com (Todd Little) writes:
  553. >
  554. >>Not so.  No where in Part 97 is the notion of "intent" for the content
  555. >>of a message covered.
  556. >
  557. >It would have been good if you had read the rules before making such a
  558. >statement:
  559. >
  560. > {deletia, to save bandwidth}
  561. >
  562. >Two people having an interactive conversation about the weather, about
  563. >their hamshacks, is what ham radio is all about.  A thousand computers
  564. >forwarding cookie recipes to ALL@USBBS is not what ham radio is about.
  565. >You know it, I know it, and this discussion has become astoundingly
  566. >boring and tedious, so while it may sadden a great many forward-
  567. >thinkers, I'm going to terminate my participation in it.
  568. >
  569. >73,
  570. >Dave, KZ1O
  571. >
  572. >-- 
  573. >Dave Bushong
  574. >OPEN/image Recognition Products
  575.  
  576. Lots of verbiage, debating a relatively simple issue. Here's my take on
  577. the discussion:
  578.  
  579. The problem is simple: there are two levels operating here. You are
  580. saying that the cookie recipe is the relevant part, that this is 
  581. 'broadcasting' or whatever, and not true ham radio communications.
  582. Other people are saying that the station-to-station packet connection
  583. is the relevant level, and what is contained in the packet is less or
  584. not relevant.
  585.  
  586. Here, I'm going to have to cast my vote with the station-to-station
  587. view. Makes more sense to me.
  588.  
  589.                   ...phil / kb8uoy
  590.  
  591. ------------------------------
  592.  
  593. End of Ham-Digital Digest V94 #366
  594. ******************************
  595.